LES PROTOCOLES TCP ET UDP

Les protocoles TCP et UDP

On présente ici les deux principaux protocoles de la couche transport d'Internet que sont les protocoles TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Tous les deux utilisent IP comme couche réseau, mais TCP procure une couche de transport fiable (alors mÊme que IP ne l'est pas), tandis que UDP ne fait que transporter de maniÈre non fiable des datagrammes.

Le protocole UDP

Le protocole UDP (rfc 768)utilise IP pour acheminer, d'un ordinateur à un autre, en mode non fiable des datagrammes qui lui sont transmis par une application (voir la figure 2.3). UDP n'utilise pas d'accusé de réception et ne peut donc pas garantir que les données ont bien été reçues. Il ne réordonne pas les messages si ceux-ci n'arrivent pas dans l'ordre dans lequel ils ont été émis et il n'assure pas non plus de contrôle de flux. Il se peut donc que le récepteur ne soit pas apte à faire face au flux de datagrammes qui lui arrivent. C'est donc à l'application qui utilise UDP de gérer les problÈmes de perte de messages, duplications, retards, déséquencement,

Cependant, UDP fournit un service supplémentaire par rapport à IP, il permet de distinguer plusieurs applications destinatrices sur la mÊme machine par l'intermédiaire des ports. Un port est une destination abstraite sur une machine identifié par un numéro qui sert d'interface à l'application pour recevoir et émettre des données. Par exemple :

tftp 69/udp

snmp 161/udp

est un court extrait du fichier /etc/services de la machine vega.info.univ-angers.fr dans lequel sont enregistrés les numéros de port utilisés par chaque application. On y voit que l'application tftp utilise le port 69 et que l'application snmp utilise le port 161. Chaque datagramme émis par UDP est encapsulé dans un datagramme IP en y fixant à 17 la valeur du protocole. Le format détaillé d'un datagramme UDP est donné dans la figure 2.23.

Figure 2.23: Structure d'un datagramme UDP.

Les numéros de port (chacun sur 16 bits) identifient les processus émetteur et récepteur. Le champ longueur contient sur 2 octets la taille de l'en-tÊte et des données transmises. Puisqu'un datagramme UDP peut ne transmettre aucune donnée la valeur minimale de la longueur est 8. Le checksum est un total de contrôle qui est optionnel car il n'est pas indispensable lorsque UDP est utilisé sur un réseau trÈs fiable. S'il est fixé à 0 c'est qu'en fait il n'a pas été calculé. De maniÈre précise, UDP utilise l'en-tÊte et les données mais également une pseudo-entÊte pour aboutir à l'ensemble décrit figure 2.24.

Figure 2.24: Champs utilisés pour le calcul du checksum UDP.

Cette pseudo en-tÊte comprend les adresses IP source et destination du datagramme ainsi qu'un éventuel octet de bourrage pour aboutir à un nombre d'octets total pair. À partir de cet ensemble, le total de contrôle est calculé de la mÊme maniÈre que dans le cas du datagramme IP. Si le résultat donne un checksum nul, son complément à 1, c'est-à-dire 65535 (16 bits à 1), est en fait placé dans la zone de contrôle. Ce détail permet d'éviter la confusion avec le checksum nul qui indique qu'il n'a pas été calculé. Précisons enfin que la pseudo en-tÊte et l'octet de bourrage ne sont pas transmis et qu'ils n'interviennent pas dans le calcul du champ longueur. À la réception, UDP utilise l'adresse IP de destination et l'adresse IP émettrice inscrite dans l'en-tÊte du datagramme IP pour calculer, de la mÊme maniÈre qu'à l'émission, une somme de contrôle qui permettra d'assurer que le datagramme est délivré sans erreur et à la bonne machine. Si une erreur de transmission est détectée, le datagramme UDP est détruit «en silence». Sinon, UDP oriente les données du datagramme vers la file d'attente associée au numéro de port destination pour que l'application associée à celui-ci puisse les y lire.

Le protocole TCP

Contrairement à UDP, TCP est un protocole qui procure un service de flux d'octets orienté connexion et fiable. Les données transmises par TCP sont encapsulées dans des datagrammes IP en y fixant la valeur du protocole à 6.

Le terme orienté connexion signifie que les applications dialoguant à travers TCP sont considérées l'une comme un serveur, l'autre comme un client, et qu'elles doivent établir une connexion avant de pouvoir dialoguer (comme dans le cas de l'utilisation du téléphone). Les ordinateurs vérifient donc préalablement que le transfert est autorisé, que les deux machines sont prÊtes en s'échangeant des messages spécifiques. Une fois que tous les détails ont été précisés, les applications sont informées qu'une connexion a été établie et qu'elles peuvent commencer leurs échanges d'informations. Il y a donc exactement deux extrémités communiquant l'une avec l'autre sur une connexion TCP. Cette connexion est bidirectionnelle simultanée (full duplex) et composée de deux flots de données indépendants et de sens contraire. Il est cependant possible d'inclure dans l'en-tÊte de segments TCP d'une communication de A vers B des informations relatives à la communication de B vers A. Cette technique de superposition (piggybacking) permet de réduire le trafic sur le réseau.

Tout au long de la connexion, TCP échange un flux d'octets sans qu'il soit possible de séparer par une marque quelconque certaines données. Le contenu des octets n'est pas du tout interprété par TCP, c'est donc aux applications d'extrémité de savoir gérer la structure du flot de données.

Si elles sont trop volumineuses, les données à transmettre pour une application sont fractionnées en fragments dont la taille est jugée optimale par TCP. A l'inverse, TCP peut regrouper des données d'une application pour ne former qu'un seul datagramme de taille convenable de maniÈre à ne pas charger inutilement le réseau. Cette unité d'information émise est appelée segment comme déjà présenté dans la figure 2.6. Certaines applications demandent que les données soient émises immédiatement, mÊme si le tampon n'est pas plein. Pour cela, elles utilisent le principe du push pour forcer le transfert. Les données sont alors émises avec un bit marquant cela pour que la couche TCP réceptrice du segment remette immédiatement les données à l'application concernée.

La fiabilité fournie par TCP consiste à remettre des datagrammes, sans perte, ni duplication, alors mÊme qu'il utilise IP qui lui est un protocole de remise non fiable. Ceci est réalisé à l'aide de la technique générale de l'accusé de réception (ACK) présentée de maniÈre simplifiée dans la figure 2.25.

Figure 2.25: Échanges de segments TCP.

Chaque segment est émis avec un numéro qui va servir au récepteur pour envoyer un accusé de réception. Ainsi l'émetteur sait si l'information qu'il voulait transmettre est bien parvenue à destination. De plus, à chaque envoi de segment, l'émetteur arme une temporisation qui lui sert de délai d'attente de l'accusé de réception correspondant à ce segment. Lorsque la temporisation expire sans qu'il n'ait reçu de ACK, l'émetteur considÈre que le segment s'est perdu et il le réexpédie. Mais il se peut que la temporisation expire alors que le segment a été transmis sans problÈme, par exemple suite à un engorgement de réseau ou à une perte de l'accusé de réception correspondant. Dans ce cas, l'émetteur réémet un segment alors que c'est inutile. Mais le récepteur garde trace des numéros de segments reçus, donc il est apte à faire la distinction et peut éliminer les doublons.

La figure 2.26 donne le format d'un segment TCP qui sert aux trois fonctionnalités de TCP : établir une connexion, transférer des données et libérer une connexion.

Figure 2.26: Format du segment TCP.

L'en-tÊte, sans option, d'un segment TCP a une taille totale de 20 octets et se compose des champs suivants :

- Le port source et le port destination identifient les applications émettrice et réceptrice. En les associant avec les numéros IP source et destination du datagramme IP qui transporte un segment TCP on identifie de maniÈre unique chaque connexion.

- Le numéro de séquence donne la position du segment dans le flux de données envoyées par l'émetteur; c'est-à-dire la place dans ce flux du premier octet de données transmis dans ce segment.

- Le numéro d'accusé de réception contient en fait le numéro de séquence suivant que le récepteur s'attend à recevoir; c'est-à-dire le numéro de séquence du dernier octet reçu avec succÈs plus 1. De maniÈre précise, TCP n'acquitte pas un à un chaque segment qu'il reçoit, mais acquitte l'ensemble du flot de données jusqu'à l'octet k-1 en envoyant un acquittement de valeur k. Par exemple, dans une transmission de 3 segments de A vers B, si les octets de 1 à 1024 sont reçus correctement, alors B envoie un ACK avec la valeur 1025. Puis, si le segment suivant contenant les octets de 1025 à 2048 se perd et que B reçoit d'abord correctement le segment des octets de 2049 à 3072, B n'enverra pas d'accusé de réception positif pour ce troisiÈme segment. Ce n'est que lorsque B recevra le deuxiÈme segment, qu'il pourra envoyer un ACK avec la valeur 3073, que A interprétera comme l'acquittement des deux derniers segments qu'il a envoyés. On appelle cela un acquittement cumulatif.

- La longueur d'en-tÊte contient sur 4 bits la taille de l'en-tÊte, y compris les options présentes, codée en multiple de 4 octets. Ainsi une en-tÊte peut avoir une taille variant de 20 octets (aucune option) à 60 octets (maximum d'options).

- Le champ réservé comporte 6 bits réservés à un usage ultérieur.

- Les 6 champs bits de code qui suivent permettent de spécifier le rôle et le contenu du segment TCP pour pouvoir interpréter correctement certains champs de l'en-tÊte. La signification de chaque bit, quand il est fixé à 1 est la suivante.

à URG, le pointeur de données urgentes est valide.

à ACK, le champ d'accusé de réception est valide.

à PSH, ce segment requiert un push.

à RST, réinitialiser la connexion.

à SYN, synchroniser les numéros de séquence pour initialiser une connexion.

à FIN, l'émetteur a atteint la fin de son flot de données.

- La taille de fenÊtre est un champ de 16 bits qui sert au contrôle de flux selon la méthode de la fenÊtre glissante. Il indique le nombre d'octets (moins de 65535) que le récepteur est prÊt à accepter. Ainsi l'émetteur augmente ou diminue son flux de données en fonction de la valeur de cette fenÊtre qu'il reçoit.

- Le checksum est un total de contrôle sur 16 bits utilisé pour vérifier la validité de l'en-tÊte et des données transmises. Il est obligatoirement calculé par l'émetteur et vérifié par le récepteur. Le calcul utilise une pseudo-entÊte analogue à celle d'UDP.

- Le pointeur d'urgence est un offset positif qui, ajouté au numéro de séquence du segment, indique le numéro du dernier octet de donnée urgente. Il faut également que le bit URG soit positionné à 1 pour indiquer des données urgentes que le récepteur TCP doit passer le plus rapidement possible à l'application associée à la connexion.

- L'option la plus couramment utilisée est celle de la taille maximale du segment TCP qu'une extrémité de la connexion souhaite recevoir. Ainsi, lors de l'établissement de la connexion il est possible d'optimiser le transfert de deux maniÈres. Sur un réseau à haut débit, il s'agit de remplir au mieux les paquets, par exemple en fixant une taille qui soit telle que le datagramme IP ait la taille du MTU du réseau. Sinon, sur un réseau à petit MTU, il faut éviter d'envoyer des grands datagrammes IP qui seront fragmentés, car la fragmentation augmente la probabilité de pertes de messages.

L'établissement et la terminaison d'une connexion suivent le diagramme d'échanges de la figure 2.27.

Figure 2.27: Etablissement et terminaison d'une connexion TCP.

L'extrémité demandant l'ouverture de la connexion, est le client. Il émet un segment SYN (oÙ le bit SYN est fixé à 1) spécifiant le numéro de port du serveur avec lequel il veut se connecter. Il expédie également un numéro de séquence initial N. Cette phase est appelée ouverture active et «consomme» un numéro de séquence. Le serveur répond en envoyant un segment dont les bits ACK et SYN sont fixés à 1. Ainsi, dans un mÊme segment il acquitte le premier segment reçu avec une valeur de ACK=N+1 et il indique un numéro de séquence initial. Cette phase est appelée ouverture passive. Le client TCP doit évidemment acquitter ce deuxiÈme segment en renvoyant un segment avec ACK=P+1.

La terminaison d'une connexion peut Être demandée par n'importe quelle extrémité et se compose de deux demi-fermetures puisque des flots de données peuvent s'écouler simultanément dans les deux sens. L'extrémité qui demande la fermeture (le client dans l'exemple de la figure 2.27 émet un segment oÙ le bit FIN est fixé à 1 et oÙ le numéro de séquence vaut N'. Le récepteur du segment l'acquitte en retournant un ACK=N'+1 et informe l'application de la demi-fermeture de la connexion. À partir de là, les données ne peuvent plus transiter que dans un sens (de l'extrémité ayant accepté la fermeture vers l'extrémité l'ayant demandée), et dans l'autre seuls des accusés de réception sont transmis. Quand l'autre extrémité veut fermer sa demi-connexion, elle agit de mÊme que précédemment ce qui entraine la terminaison complÈte de la connexion.

Le transfert de données de TCP est de deux types : le transfert interactif dans lequel chaque segment transporte trÈs peu d'octets, voire un seul, et le transfert en masse oÙ chaque segment transporte un maximum d'octets. Cette distinction est confortée par une étude de 1991 qui indique que la moitié des paquets TCP contient des données en masse (ftp, mail, news, ) et l'autre moitié des données interactives (telnet, rlogin, ). Mais, 90% des octets transmis proviennent de données en masse et 10% seulement de données interactives car il apparait que 90% des paquets de telnet et rlogin comportent moins de 10 octets.

Un exemple de transfert interactif est celui généré par la commande rlogin lancée depuis un client vers un serveur. Dans ce cas de figure, tous les caractÈres tapés par l'utilisateur sur le client sont envoyés vers le serveur en utilisant un caractÈre par segment, et ils sont ensuite renvoyés en sens inverse par le serveur pour un écho sur l'écran du client. Tous les segments échangés dans ce cas là ont leur bit PSH fixé à 1. Or, tout segment doit Être acquitté dans un sens comme dans l'autre; ce qui devrait amener au diagramme d'échanges illustré dans le a) de la figure 2.28.

Figure 2.28: Échange de données interactif.

En fait, TCP gÈre ce type d'échange avec la procédure d'acquittement retardé qui consiste à envoyer l'acquittement en l'incluant dans un segment qui transporte également des données comme illustré dans le b) de la figure 2.28. Pour cela l'acquittement est généralement retardé de 200ms dans le but d'attendre d'éventuelles données à transmettre. Cependant, dans ce contexte la frappe de la commande date sur le client provoquerait quand mÊme l'échange de 15 datagrammes IP de 41 octets, pour transporter à chaque fois seulement 1 octet utile. Ce type de situation est peu gÊnant sur un LAN mais devient trÈs vite préjudiciable au bon fonctionnement d'un WAN. Une solution à ce problÈme est l'algorithme de Nagle (RFC 896) qui spécifie qu'une connexion TCP ne peut avoir seulement un petit segment non encore acquitté. Ainsi, si un réseau a un fort débit et n'est pas du tout chargé la procédure sera celle du b) de la figure 2.28. Par contre, dÈs que le temps de transfert est non négligeable, les acquittements vont arriver plus lentement que la frappe des caractÈres par l'utilisateur du poste client. Dans ce cas, la couche TCP du client va accumuler de petits volumes de données (quelques caractÈres) et les envoyer dans le mÊme segment TCP diminuant ainsi considérablement le nombre d'échanges comme illustré dans le c) de la figure 2.28. Dans les cas oÙ de petits messages doivent Être remis sans délai (mouvement de souris dans le cas d'un serveur X) l'algorithme de Nagle doit Être invalidé pour donner une impression de temps réel.

Dans le cas d'un transfert de données en masse, TCP utilise la technique de la fenÊtre glissante pour contrôler le flux des échanges. Ceci est primordial quand un micro ordinateur communique avec un gros ordinateur, sinon le tampon d'entrée du micro sera trÈs vite saturé. Ceci consiste en un contrôle de flux de bout en bout. Mais il s'agit aussi de réguler le trafic en fonction de la charge des routeurs et du débit des réseaux traversés. On rappelle que l'ensemble d'un flux de données unidirectionnel d'une machine A vers une machine B est constitué d'une séquence d'octets tous numérotés individuellement. La fenÊtre glissante va consister à fixer quels sont les octets appartenant à ce flux que A peut émettre comme c'est illustré dans la figure 2.29.

Figure 2.29: FenÊtre glissante de TCP.

Dans cet exemple la fenÊtre couvre les octets de 4 à 9, car la taille de la fenÊtre courante est 6 et que tous les octets jusqu'au troisiÈme inclus ont été émis et acquittés.

Figure 2.30: Exemple d'évolution de fenÊtre glissante.

A tout instant TCP calcule sa fenÊtre utilisable qui est constituée des octets présents dans la fenÊtre et non encore envoyés. Ces octets sont généralement immédiatement transmis. Pour le flot de A vers B, la taille de la fenÊtre est contrôlée par B qui envoie dans chacun de ses accusés de réception la taille de la fenÊtre qu'il désire voir utiliser. Si la demande exprime une augmentation, A déplace le bord droit de sa fenÊtre courante et émet immédiatement les octets qui viennent d'y entrer. Si la demande exprime une diminution, il est déconseillé de déplacer réellement le bord droit de la fenÊtre vers la gauche. Ce rétrécissement est opéré lors des glissements de la fenÊtre vers la droite avec l'arrivée des accusés de réception.

La figure 2.30 illustre les échanges de segments entre un émetteur A et un récepteur B et l'évolution de la fenÊtre glissante de A suivant les indications de B.